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USING  TRACE  SPECIFICATIONS  FOR  PROGRAM  SEMANTICS 

AND  VERIFICATION 


1.  INTRODUCTION 

Traditionally,  program  verification  has  focused  on  proving  isolated  programs  and  their  subrou¬ 
tines  correct  vis-a-vis  their  specifications.  Unfortunately,  working  with  isolated  programs  has  resulted 
in  faulty  program  specification  [1],  The  problem  with  specifying  programs  individually  is  that  many 
programs  do  not  have  any  user-visible  effects  except  for  their  interaction  with  other  programs.  For 
example,  the  effect  of  executing  a  push  procedure  in  a  stack  module  can  be  seen  only  by  its  interac¬ 
tion  with  other  procedures  that  permit  a  user  to  examine  the  stack.  To  specify  such  programs,  veri¬ 
fiers  have  hitherto  been  forced  to  tell  programmers  too  little  about  what  to  do  and  too  much  about 
how  to  do  it.  They  have  resorted  to  pseudocode,  algorithms,  hidden  functions,  program  states,  and 
user-invisible  variables  to  describe  program  interaction.  This  leads  to  a  loss  of  specification  abstrac¬ 
tion  that  forces  the  module  programmer,  the  module  user,  and  later  the  system  maintainer  to  glean 
essentials  from  a  mass  of  implementation  clutter  [2].  Often,  they  disagree  on  what  is  essential  and 
what  is  notational  artifact.  The  result  is  often  unnecessary  module  coupling  that  makes  software 
extremely  difficult  to  maintain. 

To  alleviate  this  problem,  some  verification  methods  supplement  implementation-dependent 
specifications  designed  for  the  verifier,  with  abstract  specifications  designed  for  the  programmer,  sys¬ 
tem  user,  and  system  maintainer.  However,  there  often  has  been  a  leap  of  faith  required  to  get  from 
the  correctness  of  the  former  specification  to  the  correctness  of  the  latter.  What  is  required  is  a 
coherent  framework  that  allows  for  both  the  abstract  specification  of  interacting  modules  and  correct¬ 
ness  assertions  for  these  modules. 

The  trace  method  for  specifying  software  [2,3]  is  a  formal,  abstract  specification  language  that 
allows  the  specifier  to  describe  a  program’s  behavior  in  terms  of  other  programs  with  which  it 
interacts.  In  Ref.  2  a  formal  foundation  for  the  method  is  presented  with  several  examples  of  how  to 
apply  the  method.  This  report  continues  the  work  in  Ref.  2  by  showing  how  the  method  can  be 
extended  to  provide  a  natural  semantics  for  procedural  programming  languages.  This  semantics  pro¬ 
vides  a  coherent  framework  for  proving  programs  correct  that  avoids  the  problems  inherent  in  the 
traditional  approach. 

2.  AN  OVERVIEW  OF  THE  EXTENDED  TRACE  LANGUAGE 

We  begin  by  extending  the  trace  specification  language  so  that  it  can  describe  the  effects  of  exe¬ 
cuting  single  program  statements.  In  Ref.  2  a  trace  specification  for  a  module  consists  of  two  parts: 
(1)  a  syntax  section  that  gives  the  procedure  names  and  types  the  module  comprises,  and  (2)  a  seman¬ 
tics  section  that  gives  the  behavior  that  the  module’s  procedures  must  exhibit.  Procedure  behavior  is> 
given  by  listing  assertions  that  describe  the  behavior  of  sequences  of  procedure  calls,  written 
call{.call2 ■  ■  ■  ■  call,,,  known  as  traces.  The  assertions  are  based  on  first  order  logic,  supplemented 
by  the  predicate  L,  which  is  true  when  applied  to  a  legal  trace  (a  trace  that  does  not  cause  an  error), 
and  the  function  V ,  which  gives  a  return  value  when  applied  to  a  legal  trace  ending  in  a  function  call. 
The  null  trace,  denoted  by  [],  is  always  legal  and  is  such  that  for  any  trace  T,  T  =  \].T  =  T.  [].  Two 
traces  Tl  and  7\  are  equivalent,  written  T{  =  T2 ,  if  and  only  if  for  any  trace  T,  L(T t.T)  iff  L(T2.T) 
and  for  nonnull  T,  V{TvT)  =  V(T2.T)  if  defined.  Less  formally,  if  two  traces  are  equivalent,  then 
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they  are  indistinguishable  as  far  as  L  and  V  are  concerned  with  respect  to  future  program  behavior. 
As  an  example,  consider  the  following  specification  for  a  simple  stack: 

STACK  SPECIFICATION 


Syntax: 

PUSH:  integer 

POP:  —  integer 

Semantics: 

(1)  L(T)  -  L(T.PUSH(n)) 

(2)  L(T)  -  T.PUSH(n).POPsT 

(3)  L(T)  -  V(T.PUSH(n).POP)=n 

The  syntax  section  says  that  the  procedure  PUSH  takes  an  integer  as  a  parameter  and  that  POP 
returns  an  integer.  The  first  assertion  in  the  semantics  section  says  that  if  T  is  a  legal  sequence  of 
procedure  calls,  then  the  sequence  consisting  of  T  followed  by  a  call  to  the  procedure  PUSH  with  any 
integer  as  a  parameter  is  legal.  The  second  assertion  says  that  if  T  is  a  legal  sequence  of  procedure 
calls,  then  T  is  equivalent  to  the  sequence  of  calls  consisting  of  T  followed  by  a  call  to  PUSH  and  a 
call  to  POP .  The  third  assertion,  when  coupled  with  the  first  two,  says  that  POP  returns  the  last 
value  pushed  on  the  stack  that  has  not  previously  been  popped.  Note  that  PUSH  and  POP  are  com¬ 
pletely  and  unambiguously  specified  without  suggesting  an  implementation. 

In  Ref.  2  a  model-theoretic  semantics  specifies  what  assertions  are  semantic  consequences  of  a 
specification,  a  derivation  system  specifies  what  assertions  are  derivable  from  a  specification,  and 
completeness  and  soundness  theorems  show  that  an  assertion  is  a  semantic  consequence  of  a  specifica¬ 
tion  if  and  only  if  it  is  derivable  from  the  specification.  Among  other  things,  this  supports  coexten¬ 
sive  semantic  and  syntactic  definitions  of  totalness  and  consistency  and  formal  techniques  for  proving 
these  properties  for  a  specification.  For  our  purposes  here,  the  most  important  elements  of  this  foun¬ 
dation  are  the  following  axioms  from  the  derivation  system.  The  first  two  say  that  the  empty  trace  is 
legal  and  that  any  initial  segment  of  a  legal  trace  is  legal.  The  third  is  a  definition  of  equivalence. 

TRACE  AXIOMS 


(1)  mi) 

(2)  LfT.Tj)  -  UT) 

(3)  T,*T2  — 

(T)((L(T1.T)  —  L(T2.T))  A 
(T  *  []  - 

((3x)V(Tj.T)=x  -  V(TrT)=V(T2.T»))* 

For  proving  program  correctness  we  also  find  use  for  the  following  induction  schema: 

INDUCTION  SCHEMA 

For  any  property  P,  if  /*([])  and  P(<t>)  — ■  (•*])  •  ■  •  (xn)P(<t>.C(xx,  •  •  •,*„))  for  each  pro¬ 
cedure  call  C  that  take  n  variables  where  jc , ,  •  •  ■  are  not  in  P ,  then  P(T)  where  T  is  not 
in  P. 


♦This  is  a  simpler  definition  than  given  in  Ref.  2,  but  the  two  definitions  can  easily  be  shown  to  be  equivalent. 
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This  schema  is  sound  with  respect  to  the  semantics  given  in  Ref.  2  if  we  limit  the  domain  of  traces  to 
the  null  trace  and  sequences  of  procedure  calls.  This  was  not  done  in  the  original  presentation  where 
infinite  traces  were  allowed  for  the  sake  of  completeness.  Our  limitation  renders  the  resulting  system 
incomplete  in  the  sense  that  although  |P([]),P(C),/>(C.C),  ■  ■  •  )  |  =P(T)  in  a  specification  that  has 
the  single  parameterless  procedure  call  C,  we  cannot  derive  P(T)  from  the  given  assumption  set.  In 
general,  it  will  no  longer  be  true  that  we  can  derive  every  consequence  of  an  infinite  set  of  assump¬ 
tions  from  that  set,  but  we  can  still  derive  every  consequence  of  a  finite  set  of  assumptions  from  that 
set.  In  technical  terms,  we  have  given  up  compactness ,  but  this  is  a  small  price  to  pay  for  the  ability 
to  prove  programs  correct  [4] .  * 

We  must  also  extend  the  notion  of  trace  to  include  strings  of  program  statements.  This  necessi¬ 
tates  introducing  program  variables  and  operators  into  the  language  as  primitives  and  introducing 
statement  variables  that  are  like  trace  variables  except  that  they  range  over  sequences  of  program 
statements  instead  of  sequences  of  procedure  calls.  Since  a  sequence  of  procedure  calls  is  a  sequence 
of  program  statements,  a  sequence  of  procedure  calls  or  procedure  call  variables  is  a  valid  substitution 
instance  for  a  statement  variable.  +  We  use  T,  possibly  subscripted,  as  a  procedure  call  variable  and 
S ,  possibly  subscripted,  as  a  statement  variable.  The  rest  of  the  language  is  unaffected  except  for  the 
predicate  V .  Whereas  in  Ref.  2,  V  was  a  function  from  traces  to  value  domains,  in  the  extended 
language,  V  takes  two  arguments— a  trace  and  a  program  variable— and  returns  the  value  of  the  pro¬ 
gram  variable  after  the  execution  of  the  given  trace.  When  the  trace  ends  in  a  procedure  call  and  the 
program  variable  is  the  return  value  of  that  call,  the  second  argument  can  be  omitted.  For  all  intents, 
this  renders  the  extended  language  a  superset  of  the  original  language. t 

3.  PROGRAM  SEMANTICS 

In  this  section  we  present  a  procedural  programming  language  and  show  how  traces  can  be  used 
to  give  the  semantics  of  the  language.  §  Since  the  trace  language  contains  Boolean  expressions  and  can 
easily  be  extended  to  contain  other  data  types  such  as  integers,  lists,  or  arrays,  we  are  not  concerned 
with  their  semantics.  For  simplicity  we  limit  our  programming  language  to  Booleans,  integers,  and 
arrays  of  integers,  and  we  assume  axioms  for  integer  and  Boolean  operators.  Our  primary  focus  is  on 
giving  the  semantics  of  the  control  structures  of  our  language. 

We  limit  ourselves  to  what  Linger,  Mills,  and  Witt  call  proper  programs  [5].  These  are  pro¬ 
grams  that,  intuitively,  (a)  have  a  single  entry  point  and  a  single  exit  point,  and  (b)  for  each  line  of 
code,  have  a  control  path  through  that  line  from  the  entry  point  to  the  exit  point.  The  second  condi¬ 
tion  rules  out  programs  that  contain  code  that  is  syntactically  unreachable  or  unleavable.  For  exam¬ 
ple,  it  rules  out  programs  containing  code  of  the  form 

A:  goto  B; 
a:  =a+ 1; 

B:  goto  A; 


•See  Ref.  4  for  a  discussion  of  this  problem  with  respect  to  temporal  logic. 

tBut  a  sequence  of  program  statements  is  not  a  valid  substitution  for  a  procedure  call  variable.  The  reason  for  the 
distinction  is  to  restrict  assertions,  such  as  the  induction  schema  above,  to  sequences  of  procedure  calls. 
tThe  qualifier  is  necessary  since  in  Ref.  2  V  was  defined  only  on  legal  traces  ending  in  a  function  call,  and  in  the  extended 
system  V  can  be  defined  for  illegal  traces  as  well.  This  is  of  small  matter,  however,  since  we  can  either  alter  Ref.  2  t  fit 
by  regarding  V  as  being  defined  on  an  unspecified  set  of  traces  that  includes  its  original  domain  or  by  treating  V  as  being 
systematically  ambiguous,  letting  context  decide. 

§For  nonprocedural  languages,  such  as  Prolog  |6|,  proving  correctness  is  relatively  easy  except  for  language  idiosyncrasies 
as  described  in  Ref.  7. 
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since  no  evaluation  must  be  made  to  determine  that  the  code  from  A  to  B  is  unleavable  and  that  the 
command  a :  =a  + 1  is  unreachable.  However,  it  does  not  rule  out  programs  that  contain  code  of  the 
form 


while  (x  =  x) 

(if  (x  =  x)  then  (a:  =a+l)  else  (b:=b  +  l)} 

since  one  can  determine  that  the  loop  is  unleavable  and  that  b :  =  b  +  1  is  unreachable  only  by  exa¬ 
mining  the  expressions  contained  in  the  program. 

Excluding  nonleavable  code  and  nonreachable  code  from  our  programming  language  does  not 
reduce  expressi'  e  power  since  the  former  can  be  replaced  by  any  nonterminating  loop  and  the  latter 
can  be  excised  without  altering  program  behavior.  Nor  does  limiting  ourselves  to  programs  with  a 
single  entry  and  a  single  exit  point  reduce  expressive  power  since  we  can  always  embed  any  program 
that  violates  this  principle  within  a  proper  program.  By  limiting  ourselves  to  proper  programs,  how¬ 
ever,  we  have  a  real  gain  in  light  of  the  Structure  Theorem  [5].  This  theorem  states  that  any  proper 
program  can  be  written  in  a  language  whose  only  control  structures  besides  simple  sequencing  are 
WHILE  DO  and  IF  THEN  ELSE .  This  motivates  the  language  SIMPLE  defined  below.  As  men¬ 
tioned  above,  we  assume  the  set  VBL  of  integer  program  variables,  BOOL  of  Boolean  expressions, 
and  EXPR  of  integer  expressions.  We  are  not  interested  in  variable  declarations. 

SIMPLE 

PROGRAM  - 

PROCEDURE  NAME[(VBL, . . . , VBL)):  [RETURN(VBL)]  STATEMENT. 


STATEMENT  - 
skip  | 

ASSIGNMENT  | 

IF  THEN  ELSE  | 

WHILE  DO  | 
STATEMENT;  STATEMENT 


ASSIGNMENT  - 
VBL  :=  EXPR 

VBL  ;=  PROCEDURE  NAME[(VBL, . . . , VBL)J 


IF  THEN  ELSE  - 

if  (BOOL)  then  (STATEMENT)  else  (STATEMENT) 


WHILE  DO  - 

while  (BOOL)  (STATEMENT) 

We  assume  without  loss  of  generality  that  SIMPLE  does  not  contain  recursion  since  we  can  always 
eliminate  it  (8).  We  also  assume  without  loss  of  generality  that  all  variables  are  global  and  that 
integer  variables  are  initialized  to  0.*  Finally,  we  will  abbreviate  program  statements  of  the  form  if 
(4>)  then  |*y|  else  (skip)  as  if  (4>)  then  (7). 


•The  effect  of  local  variables  can  be  achieved  by  judicious  naming. 
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The  semantics  for  SIMPLE  is  given  by  the  following  axioms  (where  parentheses  and  brackets 
are  omitted  around  Greek  letters  for  readability): 

PROGRAM  SEMANTIC  AXIOMS 

(1)  V(S,c)=c,  for  constant  c. 

(2)  V(0,x)=0,  for  any  integer  variable  x . 

(3)  V(S.a:=t,a)=V(S,t),  for  term/. 

(4)  V(S,a  op  b)=  V(S,a)  op  V(S,b)  for  arithmetic  operation  op . 

(5)  V(S,a  op  b)  — *  V(S,a)  op  V(S,b)  for  Boolean  operation  op . 

(6)  V(S.a:=x,b)=V(S,b)  where  b  is  independent,  as  defined  below,  of  a . 

(7)  V(S»=V(S,^)  —  V(S,a[0])=V(S,a[^])  where  a  is  an  array. 

(8)  V(S,<ji)*V(S,^)  —  V(S.a[$l:=t,atyl)=V(S,a[^])  where  a  is  an  array 

(9)  V(S,<*>)  -  V(S.if  <t>  then  0  else  tf.x)  =  V(S.0,x) 

(10)  -<V(S,0)  -  V(S.if  <l>  then  0  else  *,x)  =  V(S.^,x) 

(11)  V(S. while  0  do  0,x)=V(S.if  <t>  then  {0. while  <t>  do  0),x) 

(12)  V(S.skip,t)=V(S,t),  for  term  /. 

We  say  that  a  is  dependent  on  b  if  (1)  a  is  typographically  identical  to  b  or  (2)  if  a  is  an  array 
variable  of  the  form  a[<£]  and  b  is  either  dependent  on  4>  or  of  the  form  a[^]  for  the  same  array  a. 
That  is,  a  is  dependent  on  b  if  they  are  identical,  if  a  is  an  array  variable  whose  index  depends  on 
b,  or  if  both  are  array  variables  to  the  same  array.  Note  that  in  the  second  case,  a  is  dependent  on 
b ,  but  not  vice  versa.  We  say  that  a  is  independent  of  b  if  a  is  not  dependent  on  b .  The  intuition 
behind  the  definitions  is  to  restrict  axiom  (6)  so  that  altering  a  [/]  may  alter  a  [y]  if  t  —y  and  altering 
/  may  alter,  e.g.,  a  [/]  or  a  [/  + 1], 

Although  the  axioms  are  sufficient  only  for  proving  weak  program  correctness,  i.e.,  that  if  the 
program  terminates  then  it  produces  the  correct  answer,  we  can  extend  them  to  prove  strong  program 
correctness,  i.e.,  that  the  program  is  weak  correct  and  terminates,  in  a  straightforward  manner. 
Clearly,  a  nonrecursive  SIMPLE  program  terminates  if  all  of  its  loops  terminate,  so  we  can  restrict 
ourselves  to  loop  termination.  Consider  the  relation  ACC (<(>,$, 6),  which  intuitively  says  that  trace  0 
can  be  formed  from  trace  <t>  by  appending  zero  or  more  occurrences  of  \p.  We  can  recursively  define 
such  a  predicate  by  adding  the  following  axiom  to  our  system: 

(13)  ACC(R,S,R)  A  (ACC(R,S,T)  -  ACC(R,S,T  S)) 

Given  this  axiom,  we  can  replace  axiom  (11)  by  the  following  axiom,  which  enables  us  to  prove 
strong  correctness: 

(IT)  (-»  V(S,^)  A  ACC(T,0,S))  —  V(T. while  ^  do  0,x)=V(T.if  4>  then  {0. while  4>  do  0),x) 

We  can  add  axioms  for  proving  termination  of  recursive  programs  in  a  similar  manner,  but  for  sim¬ 
plicity,  we  shall  limit  ourselves  to  the  original  12  axioms  in  the  rest  of  this  report. 

The  axioms  are  based  on  the  standard  Hoare  axioms  [9]  for  weak  correctness.  However,  the 
semantic  axioms  given  here  differ  from  Hoare’s  in  that  they  are  stated  in  terms  of  variable  values 
instead  of  in  terms  of  general  preconditions  and  postconditions.  A  Hoare-style  assertion  such  as 
A\p)B  (if  A  is  true  before  executing  program  p,  then  B  is  true  after  completion  of  p)  can  be 
stated  in  the  present  system  as  AT  —  BT  where  AT  is  the  same  as  A  except  that  every  term  t 
is  replaced  by  V(S ,/)  for  some  statement  variable  5,  and  BT  is  the  same  as  B  except  that  every  term 
/  is  replaced  by  V(S.p,t).  Hence,  jc  =0{jc :  =x  + 1  ;y :  =x )y  =  1  is  equivalent  to  V(Sj) 
=0  —  P(5.x:=x  +  l.y:=x,y)  =  l. 


It  might  seem  as  though  the  correct  translation  should  be  K(0^c)=0  —  V(S.x  :  =x  + 1  ,v : 
= or  ,y )  =  1 .  However,  such  a  strategy  fails  when  we  consider  the  assertion  x  =  1  [x :  =  x  + 1  ;y :  =x  )y  =  1 
since  P(Q^c)-l  is  false  given  our  assumption  that  all  uninitialized  integers  are  0.  If  there  is  no 
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sequence  of  programs  that  can  set  x  to  0,  then  P(S,jc)=0  will  also  fail  to  hold  for  all  S.  This  may 
seem  to  be  a  disadvantage  of  the  trace  approach,  but  it  fits  well  with  our  desire  for  abstraction.  If  a 
certain  state  is  unrealizable  by  a  module,  we  have  no  business  placing  restrictions  on  what  would 
happen  if  that  state  were  realized.  Further,  if  we  assume  that  our  language  contains  a  deterministic 
assignment  statement  such  as  epitomized  by  x:=0,  then  all  possible  states  are  realizable. 

Since  we  can  translate  Hoare-style  assertions  into  trace  assertions,  we  can  define  any  language 
construct  that  is  definable  by  Hoare-style  assertions.  For  example,  consider  Dijkstra’s  if  fi  and  do  od 
constructs  [10].  The  semantics  for  the  former  is  given  by  the  two  axiom  schemata  ((K(S,Z>,) 
V  ■  ■  ■  V  K(S,6n))  A  F(S,Z>,)  -  V(S.pl,x)=4>  A  •  •  •  A  V(S,bn)  -  V(S.p„,x)=<j>)  -  V{S.ifbx  — 
P\\  ■  ■  ■  \bn-pnfi,x)  =  (t>  and  ~>(V(S,bx)  v  -  v  V(S,bn))~  ->(3y)V(S.ifbx~px\  ■  ■  ■ 

|  bn  ~~Pnfi  rX )  =y .  The  semantics  for  the  latter  is  given  by  V(S.do  b,— p,|  ■  ■  ■  \bn-~pnod  ,x)  = 
V(S.if(bl  V  •  •  •  v  b„)  then  (if  bx-px  |  •  ■  •  \bn  - pnfi;  do  bx~px  |  ■  •  •  \b„  ~pnod\,x). 

An  advantage  of  the  semantic  axioms  given  here  is  that  when  using  them  for  proving  programs 
correct,  we  do  not  have  to  worry  about  finding  proper  initial  conditions.  Finding  such  conditions  for 
Hoare-style  axioms  is  a  nontrivial  task  often  neglected  in  the  literature.  A  second  advantage  is  that 
we  allow  trace  variables.  This  gives  us  a  more  expressive  language.  For  example,  although  our 
stack  assertion  (3)  can  be  rendered  as  the  Hoare-style  assertion  true \PUSH(n). POP \return  =n ,  we 
cannot  capture  by  any  Hoare-style  assertion  assertion  (2)  of  our  specification.  It  may  seem  as  though 
P  [PUSH (n). POP }P ,  i.e.,  whatever  is  true  before  calling  PUSH  then  calling  POP  is  true  after  the 
calls,  approximates  our  concept  of  equivalence,  but  this  is  not  the  case.  It  is  not  the  case  that  any¬ 
thing  that  is  true  before  PUSH  (n). POP  is  true  after  PUSH (n). POP ,  only  that  anything  that  is  user 
visible  that  is  true  before  the  call  is  true  after  the  call.  For  example,  if  our  stack  is  implemented  as 
an  array,  the  array  state  will  be  different,  but  not  in  a  way  that  a  module  user  can  detect.  More  on 


this  in  the  next  section. 


Our  language  can  also  express  assertions  of  dynamic  logic  [11]  if  we  allow  for  nondeterminancy 
by  letting  V  return  a  set  of  values  [12],  thus,  treating  V  as  a  relation  rather  than  as  a  function.  The 
result  is  a  formulation  of  dynamic  logic  that  employs  standard  first  order  model  theory  instead  of  co- 
sequences  of  models.  For  example,  if  we  let  K(5,f  ,v)  mean  that  the  value  of  t  can  be  v  after  execut¬ 
ing  5,  then  the  U  construct,  which  has  the  property  that  pUq  executes  either  program  p  or  q,  can 
be  specified  by  V(p  Uq  ,t  pc)  —  V(p,tpc)  v  Vfq,tpc).  Similarly,  the  *  construct,  which  has  the 
property  that  for  any  program  p,  p*  executes  p  0  or  more  times,  can  be  specified  by  the  axiom 
schema  V(p*  ,t  pc, )  where  x,  is  the  value  of  executing  p  i  times.  The  statement  x  =0  —  <p>x  =  1 
(i.e.,  if  x  =0  then  jc  =  1  is  true  in  some  state  reachable  by  executing  program  p)  is  represented  by 
(v)(K(S,jc,v)  —  v  =0)  —  VfS.p pc,\),  and  x  =0—  \p\x  =  1  (i.e.,  if  x  =0  then  x  =  1  is  true  in  every 
state  reachable  by  executing  program  p)  is  represented  by  (v)(K(S,x,v)  —  v=0)  — 
(v)(V(S.ppc ,v)  —  v  =  l).*  Analogous  comments  apply  here  as  were  given  when  considering  the 
Hoare-style  approach.  The  translations  are  faithful  if  we  consider  the  antecedent  x  =0  to  apply  only 
to  states  that  are  realizable  by  a  sequence  of  procedure  calls.  Further,  we  must  assume  that  this 
sequence  always  leads  to  a  state  in  which  x  =0.  As  above,  these  restrictions  are  easy  to  satisfy  if  we 
assume  that  we  have  deterministic  assignment.  Some  of  the  advantages  of  our  approach  over  dynamic 
logic  are  analogous  to  the  advantages  of  our  approach  to  that  of  Hoare-style  logic.  A  further  advan¬ 
tage  is  that  we  avoid  the  complicated  model  theory  that  dynamic  logic  necessitates  since  we  do  not 
need  to  consider  co-sequences  of  program  states. 


4.  PROGRAM  CORRECTNESS 


As  an  example  of  a  program  correctness  proof,  consider  the  following  program  for  computing 
factorial: 


♦Of  course,  the  relational  counterpart  of  V  can  also  be  used  to  give  semantics  for  If  fl  and  do  od 


icy 

>r« 
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FACTORIAL  PROGRAM 

FAC(n):  RETURN(fac) 

fac:  =  1; 

i:  =n; 

while  (i  >  0) 

{fac:  =  fac*i; 
i:=i-l). 

We  prove  FAC  correct  with  respect  to  the  simple  specification  F(F4C(0))  =  1  A 
C*>0  —  V{FAC(x  + 1))  =  (jc  +  l)*K(F4C(x)))  by  deriving  the  specification  from  FAC,  our  program 
semantic  axioms,  and  the  trace  axioms  of  Ref.  2. 

We  consider  each  conjunct  in  turn.  The  specification  then  follows  by  simple  sentential  logic. 
To  derive  V(FAC(0))  =  1 ,  note  that  by  definition  V(FAC(0))  =  V(fac:  =  l.i :  =  0.  while  (i 
>0)( fac :  =  fac*i  \i :  =  i  -\),fac).  By  axiom  (11),  this  is  equal  to  V(fac:  =  \.i:=0.if(i  >0)  then 
[fac:  =fac*i ;/:=*  —  1;  while  (i  >0)[fac:  =fac*i ;/:=/  —  \,))fac).  Since  by  axiom  (1)  V ( fac :  = 
l.i' :  =0,/)=0,  we  can  use  axiom  (10)  (and  implicitly  axiom  (12))  to  derive  V(FAC( 0))  = 
V(fac:  =  l.i :  =0 fac).  By  axioms  (6)  and  (1),  Vfac :  =  1 ./ :  =0fac)  =  1,  and  we  are  done. 

To  derive  jc>0  —  V(FAC(x  + 1 ))  =  (jc  +  \)*V (FAC (x))  requires  a  lemma.  We  prove  by  induc¬ 
tion  on  the  integers  that  for  any  integer  m,  (m=V(Si ,/ )  A  m=V(S2,i)  A  V(Sx,fac)  =  V 
(S2fac)*y)  —  K(S(  .while(i>0)  [fac:=fac*i\i:=i  —  \\fac)  =  V (S2. while (i  >0)  [fac:  =fac*i\ 
/':=/-  \\fac)*y.  It  is  trivial  to  prove  this  for  m  =0  so  we  assume  it  for  m  =n  >0  and  show  it  for 
m  =n  +1.  Note  that  if  m=n+ 1  and  n  >0,  then  by  using  axiom  (11)  the  lemma  is  equivalent  to 
(«  +  l  =  K(S1,i)  A  n  +  l  =  K(S2,i)  f\V{Sx,fac)  =  V  (S2,fac)*y)  —  V(Svfac:~fac  *i.i:=i -1. while 
(/  >0)  [fac :  =  fac*i  ;/:=/- 1 )  fac )  =  V(S2.fac:=fac  *i.  i:=i  -  \.  while  (i  >  0)  [fac  :=fac*i  \i  :—i 
—  \  \,fac)*y.  But  (n+l  =  F(S[,i)  A  «  +  l  =  K(S2,0-*  «  =F(Sj./ac:=/ac  */./:=/ -\,i)  =  V  ( S2 . 
fac :  —fac  *i.i:=i- 1,/).  Further  (F(S,,/ac)  =  K  ( S2,fac)*yf\  V{Sui)  =  V  (S2,i»  -  V{S,.fac: 
-fac  *i.i :  =/  —  [,fac)  =  V  {S2. fac  : -fac  *i.i:=i  —  \,fac)*y.  Hence,  by  the  induction  hypothesis, 
since  S (  and  S2  are  statement  variables,  V(Sx.fac:=fac  *i. i:=i  -  while (i  > 0)  [fac:=fac*i ; 
i:=i  -\\,fac)  =  V(S2.fac:=fac  *i. i:-i  -  while (i  > 0)  [fac:=fac*i;i:=i -\},fac)*y,  and  we  are 
done  with  our  lemma. 

We  can  now  derive  jc>0  —  V  {FAC(x  +  l))  =  (;c  + 1)  *V(FAC(x)).  Note  that  V(fac:  =  l.i:  = 
x,i)=x  and  V(fac:  =  1./ :=x  +  l.fac:  =fac*i.i:  =i  —  1,i)=jc.  Also,  V(fac:  =  \.i:  =x,fac)*(x  + 1) 
=  V(fac:  =  l.i :  =x  +  X.fac:  =fac  *i.i:=i -l,fac).  Therefore,  by  our  lemma,  V(fac:  =  1 ./ :  =x. 
while(i>0)  [fac :  =fac*i  ;i :  =i  - 1  \,fac)*(x  + 1)=  V{fac:  =  \.i:=x +  \.fac:—fac  */./:=/ -[.while 
(i  >0)[fac:=fac*i ;i :  =i  -\],fac).  But  V (fac :  =  l.i  :=x. while (i  >0)[fac:=fac*i ;/ :  =i  -\\,fac) 
=  V(FAC{x)),  and  jc>0->  V(fac :  =  l.i:  =x  + 1  fac :  =fac  *i.i:=i -[.while  {i  >0)  { fac:=fac*i\ 
i :=/ -l],fac)=  V(FAC(x  + 1)).  Hence,  *>0  —  V(FAC(x))  *(x  +  l)  =  V  (FAC{x  + 1)),  and  we  are 
done. 


As  a  second  example  of  a  program  correctness  proof,  consider  the  stack  specification  given  in 
Section  2.  In  this  section  we  show  how  to  prove  a  SIMPLE  implementation  of  the  specification  to  be 
correct.  We  use  the  following  program  where  ptr  and  top  are  integer  variables  and  stack  is  an 
integer  array. 

STACK  PROGRAM 


PUSH(i): 

if  (ptr>0)  then  {ptr  :=  ptr+1;  stack[ptr]:=  i). 

POP:  RETURN(top) 

if  (ptr>0)  then  {top:  =  stack[ptr]|; 

ptr:  =  ptr- 1 . 
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As  before,  a  correctness  proof  consists  of  a  derivation  of  the  specification  from  the  program 
using  the  the  axioms  of  Ref.  2  and  the  axioms  that  define  the  semantics  of  SIMPLE.  However,  this 
is  not  as  straightforward  as  the  in  factorial  case.  It  is  not  clear  how  to  treat  some  of  the  constructs 
found  in  our  specification  [1].  For  example,  although  it  is  clear  how  to  derive  the  assertion 
V(PUSH(n).POP)=n ,  it  is  not  clear  how  to  derive  L(T)  —  V  (T. PUSH (n). POP)  =n .  We  could 
side-step  this  problem  by  rewriting  our  program  so  that  V(T.PUSH(n).POP)=n  is  always  true. 
However,  such  a  "solution"  may  not  always  be  available.  Further,  legality  is  not  the  only  trouble¬ 
some  concept;  the  same  problem  arises  for  equivalence  as  well. 

What  is  clearly  needed  are  program-counterparts  to  legality  and  equivalence.  Logically,  this  is 
equivalent  to  giving  an  interpretation  for  the  two  predicates,  which  is  perfectly  all  right  as  long  as  the 
interpretation  preserves  the  truth  of  the  relevant  axioms  from  the  trace  derivation  system.  Intuitively, 
a  stack  trace  is  legal  if  it  does  not  try  to  pop  an  empty  stack.  Since  popping  an  empty  stack  decre¬ 
ments  the  variable  ptr  below  0  and  a  negative  ptr  can  never  become  nonnegative,  we  can  say  that  a 
trace  T  is  legal  iff  V(T,ptr)>0.  Two  traces  Tx  and  T2  are  equivalent  if  they  have  the  same  value 
for  ptr  and  the  same  value  for  the  variables  stack [  1],  •  •  •  ,stack\ptr].  In  other  words  T ,  is 
equivalent  to  T2  iff  V(Tx,ptr)  =  V  (T2,ptr)  a  (l  <(  <  V  ( Tuptr )  —  V  (T , , stack [i' \)  =  V (T2,stack [i ])). 
For  correctness,  we  need  to  establish  that  the  relevant  legality  and  equivalence  axioms  of  Ref.  2  hold 
for  our  interpretation  and  that  we  can  derive  the  stack  specification  given  our  interpretation.  In  other 
words,  we  must  show  that  we  can  derive  the  stack  specification  and  our  three  trace  axioms  from  our 
program  semantic  axioms,  our  stack  implementation,  and  the  two  axioms  L(T)  *—  V  (T,ptr)>0  and 
Tx  =  T2  — *  (V(Tx,ptr)  =  V  ( T2,ptr )  A  (l<i  <V  ( Tuptr )  -  V  ( Titstack[i))  =  V  ( T2,stack[i ]))). 

It  is  up  to  the  programmer  to  provide  these  program-relative  definitions  for  legality  and 
equivalence .  The  programmer  should  formulate  them  as  the  program  is  being  written  and  use  them 
to  verify  informally  the  code.  The  program  verifier  uses  them  to  derive  formally  the  specification. 
This  is  equivalent  to  using  our  implementation  and  program  semantic  axioms  to  derive  the  following 
assertions: 


STACK  CORRECTNESS  ASSERTIONS 

(1)  V(T,ptr)  >0  -  V(T.PUSH(n),ptr)>0 

(2)  V(T,ptr)>0  -  (V(T,ptr)=V(T.PUSH(n).POP,ptr)  A  (1  <i< V(T,ptr)  -  V(T,stack[i])  = 
V(T.  PUSH(n).  POP,stack[i]))) 

(3)  V(T,ptr)>0  -  V(T.PUSH(n).POP,top)=n 

(4)  V([],ptr)>0 

(5)  V(T.T,  ,ptr)  >  0  -  V(T,ptr)  >  0 

(6)  (V(T,ptr)  =  V(T i.ptr)  A  (1  <isV(T,ptr)  -  V(T,stack[i])  =  V(T ,,stack[i])))  — 

(T2>((V (T T2,ptr) ^ 0  —  V(T,.T2,ptr)>0)  A  (T2*[ ]  -  ((Ev)V(T.T2)=v  - 
V(T.T2)=V(T  ,.T2)))) 

The  derivations  of  these  assertions  are  included  as  an  appendix  to  this  report.  Here,  it  is 
worthwhile  to  consider  the  assertions  themselves.  Assertions  (1)  to  (3)  correspond  to  assertions  (1)  to 
(3)  of  the  stack  specification,  and  assertions  (4)  to  (6)  correspond  to  trace  axioms  (1)  to  (3)  given 
above.  These  assertions  are  “implementation-relative”  versions  of  the  corresponding  specification 
assertions  and  trace  axioms.  This  does  not  imply  that  the  original  implementation-free  versions  are 
functionless,  however.  The  implementation- free  specification  provides  a  foundation  for  all  implemen¬ 
tations;  it  is  what  the  programmer  uses  to  understand  what  the  module  should  do.  Similarly  the 
implementation- free  trace  axioms  provide  a  foundation  for  all  specifications.  The  programmer  uses 
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both  to  formulate  program-relative  concepts  of  legality  and  equivalence.  If  we  were  to  consider  a  dif¬ 
ferent  implementation,  say  one  where  the  stack  was  implemented  as  a  linked  list,  a  variable-length 
character  string,  or  a  Godel  number,  the  correctness  assertions  might  differ  to  reflect  different 
program-relative  definitions  of  legality  and  equivalence ,  but  they  would  still  be  counterparts  of  the 
same  specification  assertions  and  trace  axioms.  The  advantage  of  the  trace  approach  is  that  it  com¬ 
bines  abstract  specifications  with  program  correctness  statements  in  a  coherent  manner.  The  program 
specification  leaves  the  programmer  free  to  choose  the  best  implementation,  yet  provides  a  framework 
for  the  programmer  to  formulate  program  correctness  assertions  from  the  program  later. 

Note  that  if  we  used  a  faulty  counterpart  for  legality  or  equivalence,  we  would  be  unable  to 
prove  the  counterparts  of  our  trace  axioms.  For  example,  if  we  called  a  trace  T  legal  if 
V(T,ptr)> 0,  then  we  would  have  been  unable  to  prove  that  L([]).  Hence,  although  some  care  may 
be  required  in  finding  the  correct  counterparts  to  equivalence  and  legality,  our  choice  is  subject  to 
verification.  Further,  since  all  our  derivations  are  formalizable  in  a  rigorous  deductive  system,  com¬ 
puter  verification  of  their  correctness  is  straightforward. 

As  a  final  example,  consider  the  following  specification  for  a  sorting  bag  for  integers. 

SORTING  BAG  SPECIFICATION 


Syntax: 

ADD:  integer 
FRONT :  —  integer 
REMOVE: 

Semantics: 

(1)  L(T)  -  L(T.ADD(n). REMOVE) 

(2)  L(T)  -  T. ADD(n). FRONT  =  T.ADD(n) 

(3)  V(T.ADD(n).T1.FRONT)=n  -  T.ADD(n).T ,.REMOVEsT.Ti 

(4)  V ( ADD(n) .  FRONT) = n 

(5)  V(T.FRONT)<n  -  V (T . ADD(n) . FRONT) = V (T. FRONT) 

(5)  V(T.FRONT)>n  -  V(T . ADD(n) .FRONT) = n 

Intuitively,  ADD  adds  integers  to  the  bag,  FRONT  returns  the  smallest  value  of  an  integer  in  the  bag, 
and  REMOVE  removes  a  smallest  integer.  The  following  program  implements  that  bag: 

SORTING  BAG  PROGRAM 


ADD(n): 
i:  =  1; 

while  (n<bag[i]  &  i < tail)  (i:=i+l); 
bag:  =INSERT(bag,i,n); 
tail:  =tail  + 1. 

FRONT:  RETURN(front) 
front:  =bag[tail). 

REMOVE: 

if  (tail  >0)  then  {tail:  =  tail  —  1 1. 

The  implementation  stores  the  inserted  integers  in  descending  order  in  an  array  and  uses  the  pro¬ 
cedure  INSERT(array, index, integer),  which  inserts  the  given  integer  at  the  indexed  location  in  the 
given  array.  For  proving  correctness,  we  can  either  use  an  implementation  of  INSERT  or  use  a 
specification  of  INSERT  if  an  implementation  is  not  yet  at  hand.  For  definiteness,  we  assume  that 
INSERT  meets  the  following  specification: 
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INSERT  SPECIFICATION 

Syntax: 

INSERT:  array  x  integer  x  integer  —  array 

Semantics: 

(1)  V(T.INSERT(x,y,z))=w  -  w[y]=z 

(2)  V(T.INSERT(x,y,z))=w  —  (i<y  —  w[i]  =  x[i]) 

(3)  V(T.INSERT(x,y,z))=w  -  (i>y  -  w[i]=x[i-l]) 

As  before,  to  formulate  correctness  assertions  we  need  program-relative  versions  of  legality  and 
equivalence.  Notice  that  a  trace  is  legal  if  it  does  not  call  FRONT  or  REMOVE  on  an  empty  bag, 

i.e.,  when  tail  =0.  This  gives  us  the  following  axiom  for  legality:  L(T)  —  (((3T  {)(T  =  T{.  FRONT 
vr  =  T,. REMOVE)  A  V(T,tail)>0)  V V(T,tail)>0).  This  axiom  could  be  simplified  if  we  altered 
our  implementation  to  set  tail  to  a  negative  integer  when  FRONT  or  REMOVE  are  illegally  called. 
Then,  the  axiom  L{T)  —  V(T,tail)> 0  would  suffice.  In  general,  program  overkill  can  make  pro¬ 
gram  correctness  easier  to  prove.  As  for  equivalence,  note  that  two  traces  are  equivalent  if  they  are 
co-legal  and  have  the  same  bag.  This  leads  us  to  the  following  axiom:  TX  =  T2  *—  ((L(T |)  —  L 
(T2))  f\V{T\,tail)  =  V(T2,tail)  A  (1<i  <V(Tlttail )  —  V(Tubag[i])  =  V  (T2,bag [/]))).  A  correctness 
proof  consists  of  a  derivation  of  our  trace  axioms  and  program  specification  from  our  two  new 
axioms,  the  bag  implementation,  and  our  program.  As  before  we  could  use  the  two  axioms  to  refor¬ 
mulate  the  trace  axioms  and  program  specification  if  desired. 

5.  CONCLUSIONS 

We  have  found  traditional  methods  for  proving  program  correctness  lacking  in  that  they  depend 
on  unacceptable  specification  methods  or  require  a  leap  of  faith  to  bridge  the  gap  between  an  accept¬ 
able  specification  and  a  program-relative  one.  In  this  report,  we  extended  a  formal  abstract  specifica¬ 
tion  language  to  a  program  semantics  language,  compared  the  extended  language  with  other  program 
semantic  languages,  and  showed  how  it  can  be  used  to  prove  program  correctness  vis-a-vis  an 
acceptable  specification. 
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This  appendix  contains  derivations  of  the  correctness  assertions  for  our  stack  implementation 
given  above.  Proving  assertions  (1),  (3),  and  (4)  are  easy  given  that  a  sequence  of  procedure  calls  or 
procedure  call  variables  is  a  valid  substitution  instance  of  a  statement  variable.  Assertion  (4)  follows 
directly  from  program  semantic  axiom  (2),  given  the  theorem  for  number  theory  that 
V([\ptr)=0  —  V([]ptr)>Q.  Assertion  (1)  follows  from  number  theory  and  our  program  semantic 
axioms  given  that  PUSH  (n)= if  (ptr  >0)  then  [ptr:— ptr  +  \\stack\ptr]:=n\.  By  program  axiom  (9) 
V(Tptr)>Q  —  V(T.if  (ptr  >0)  then  [ptr:=ptr  +  \,stack\ptr]:=n)ptr)  =  V(T.ptr:=ptr +  \;stack 
lptr\:=n  ptr),  and  V(T.ptr :  -ptr  +  \\stack\ptr]\  =n  ,ptr)  =  V(Tptr)  +  (  by  axioms  (6),  (3),  (4)  and 
(1).  Hence,  by  number  theory  we  have  assertion  (1).  Assertion  (3)  follows  by  analogous  reasoning 
given  that  POP  =  if  (ptr  >Q)  then  ( top.-stack\ptr]).ptr\=ptr  —  \  and  the  fact  that  V(T,ptr)>0  — 
V(T.PUSH(n  )ptr)  =  V(Tptr)+  1. 

We  prove  assertion  (2)  in  two  parts,  one  for  each  disjunct  of  its  consequent. 
V(T,ptr)>0  —  V (T ,ptr)  =  V (T. PUSH (n). POP  ptr)  is  straightforward  given  our  program  semantic 
axioms  and  the  implementations  of  PUSH(n)  and  POP.  This  leaves  V(Tptr)>0 

—  (1  s/ <  V(Tptr)  —  V(T,stack[i ])  =  V (T. PUSH (n). POP , stack [i])).  Note  that  i  s.  V(Tptr)  — 

V(T,i)±V  (T.ptr:=ptr +  lptr).  Given  this,  deriving  V(T,ptr)>  0—  (I</<F(7\pfr)-* 

V(T  ,stack[i])-V  (T.PUSH (n).POP  .stack [i ]))  is  straightforward  using  program  semantic  axioms  (6) 
and  (8).  Assertion  (2)  follows  by  logic. 

i 

Instead  of  proving  assertion  (5)  directly,  we  prove  its  contrapositive,  V(Tptr)<0 

—  V(T.Tuptr)<0,  by  trace  induction.  Assertion  (5)  follows  by  simple  sentential  logic.  Let  P  be 
the  property  such  that  P(<t>)  if  and  only  if  V(<f>,ptr)< 0  —  V((/>.Tlptr)< 0.  We  prove  P(T),  and 
thereby  assertion  (5),  by  using  our  induction  schema.  /*([])  is  V([\,ptr)< 0  —  K([].7'1,ptr)<0, 
which  is  trivial  since  V([]ptr)  = 0  by  program  axiom  (2).  P(<f>)  —  P(<t>.PUSH(i))  is  (V(<j)ptr)<0 

—  V(<t>.T]ptr)<0)  —  (V (<j>. PUSH (i), ptr )<0  —  V(<j>. PUSH (i).T^ ptr ) < 0) .  We  establish  this  by 

proving  its  consequent  by  induction.  Let  A  be  the  property  such  that  A  (\p)  if  and  only  if  V 
(<t>. PUSH (i) ptr) < 0—  V (<t>. PUSH (i).\p ptr) < 0.  We  want  to  establish  ACT,).  A ([])  is  the  assertion 
V (<f>. PUSH (i) ptr) < 0  —  V(<t>.PUSH(i).[]ptr)< 0,  which  is  trivially  true  since  <t>. PUSH  =  </>. PUSH 
(/).[].  A  (\p)  —  A  (\p.PUSH(i))  is  the  assertion  (V (<j>. PUSH (i) ptr) < 0  —  V (<j>. PUSH (i). \pptr ) 
<0)  -  (V(<j>.PUSH(i)ptr)< 0  -  V(<t>. PUSH (i).^.P USH(i ) ptr ) < 0) .  Now  V(<$>.PUSH(i)4ptr) 
<0  —  V (<j>. PUSH (i).\p. PUSH (i) ptr) <0,  since  PUSH (i).\p ptr) < 0  —  V(<f>.PUSH(i).\pptr)  = 

V(<f>.PUSH(i).yp.PUSH(i)ptr)<  0.  A(\p)  —  A(\{/.PUSH(i))  follows  by  sentential  logic  since 

(B  —  C)  —  ((A  —  B)-»  (A  —  C)).  A(\f/)  —  A ty. POP)  is  the  assertion  ( V(<j>.PUSH(i)ptr ) 
<0  -  V(<t>.PUSH(i).  iptr)< 0)  -  (P(<*>. PUSH (i) ptr)  <0  -  V(<t>.PUSH(i).  POP  ptr)  < 0). 
This  holds  by  an  analogous  argument,  establishing  A(T\)  and  hence,  P(<t>)  —  P(4>.PUSH(i)). 
P(<t>)  —  P(4>.POP)  holds  by  an  analogous  argument,  which  establishes  P(T),  and  we  are  done. 

We  prove  assertion  (6)  by  establishing  four  lemmas.  First,  consider  (I)  V (T ptr)  =  V (T {ptr)  — 
(V(T.T2ptr)> 0  — V(T]  .T2ptr)>0).  Using  induction  on  T2,  it  is  straightforward  to  establish  that 
V(T ptr)  =  V(Ttptr)  —  V(T.T2ptr)  =  V  (T].T2ptr),  from  which  (I)  follows.  Next  consider  (II) 
(V(T ptr  )  =  V(T\ptr)  A  (1  </ <  V(Tptr)  —  V(T ,stack\i\)  =  V  (Tustack\i ])))  —  (^^II  —  ((3v)V 
(T.T2)  =  y  —  V  (T.T2)=V  (TvT2))).  Unabbreviating  V.  this  translates  into  (V(T ptr)  =  V(T]ptr)  A 
( 1  <i  <  V(Tptr)  —  V(T ,slack[i\)  =  V(T\,stack[i\)))  —  (T2  POP  * []  —  ((3v )V (T.T2.POP ,top)  = 
v  —  V(T.T2.POP ,top)  =  V(Tl.T2.POP ,top))).  Using  induction  on  T2,  it  is  straightforward  to  prove 
( V(T ptr)  =  V  (Txptr)  A  (1  Si  <,  V(Tptr)  —  V(T ,stack[i])-V  (Tustack [/])))  —  V(T.T2.POP  Jop) 
=  V  (T\.T2.POP .top),  from  which  (II)  follows.  Next,  consider  (III)  (T2)  (V(T.T2ptr)^0  —  V 


NRL  REPORT  9033 


( Tx.T2,ptr)>0 )  —  V(T,ptr)  =  V  ( Tx,ptr ).  We  establish  (III)  by  proving  V(T,ptr)>  V(T{, 
ptr)  — •  (3T2)  ( V(T.T2,ptr)>0  —  ^(7). 7’2,p/r)<0)  from  which  (III)  follows.  By  definition, 
V(T ,ptr)>V(T{,ptr)  —  (3x)(3y)(y  >0  A  (/(T],p?r)=jc  A  V(T  ,ptr)=x  +y).  Integer  induction  on  x 
proves  that  (X  )(y  )(y  >  0  A  .t>0  A  V(Tl,ptr)=x  A  V(T,ptr)=x  +y)  —  (3T2)(V(T.T2,ptr)>0  A 
KITp T2,ptr) <0).  For  x  =0,  T2=POP,  and  for  x=m  + 1,  T2  =  T2.POP  where  T3  works  for  m. 
Negative  integer  induction  on  x  proves  that  (y  > 0  A  jc<0  A  K(7],/j?r)=x  AV(T,ptr)=x  +y)  — 
(3T2)(V(T.T2,ptr)>0  A  K(7,.r2,ptr)<0).  Forjc  =  -l,  T2-PUSH{n),  and  for  x=m  —  1,  T2  = 
TyPUSH{n ),  where  P3  works  for  m.  This  establishes  (III).  Finally,  we  prove  (IV)  (T2) 
{(V{T.T2,ptr)>0  —  V(T  x.T2,ptr)>Q)  A  (72*[]  -  ((3v)V(T.T2)=v  -  V(T.T2)  =  V(TvT2)))) 

—  (1  </ <  F(7,p/r)  —  F(r,5McA:t/])  =  I/(T1,5tacktt]))-  Unabbreviating  V,  this  translates  to  (T2) 
((V(T.T2,ptr)  >0—  V(Tx.T2,ptr)  >0)  A  (72.POP  *[]  -  ((3 v )  K(7.72.  POP ,top)  =  v  -  V  (T.T2. 
POP  ,top)  =  V  (T  x.T2.POP  ,top))))  —  (1  <i  <  V(T,ptr)  —  F(T,s/ack[/])  =  F  (Testae/:!/])).  Using 
logic  and  lemma  (III),  (IV)  follows  from  (1  </ <  V(T, ptr)  A  V  (T, stack  [i])i^  K(7t, stack  [/])  A 
F(7,ptr)  =  K  (7,,ptr))  -  (3T2)  (T2.POP  *[]  A  (3v)V  (7.72.POP ,top)  =  v  A  K(7.72.  POP, 
top)&V(Tx.T2.  POP, top)).  This  last  assertion  can  be  proven  by  integer  induction  on  i,  and  we  are 
done. 


